1. Field of the Invention
The present invention is generally related to computer systems that provide for the inter-networked simultaneous sharing of information and, in particular, to a collaborative computer application system that provides for a virtual shared application space.
2. Description of the Related Art
With the recent expansion in the variety of information technologies and the distribution of information among network interconnected, or inter-networked computer systems and users, a need has arisen to coordinate the exchange and development of information by users typically at separate and potentially heterogeneous computers systems. In many of these instances, the information that needs to be shared or created requires the collaborative or effectively simultaneous use of some particular application. In many of these instances, the application has been originally designed and implemented to utilize a virtual display window created within and managed by a graphical user interface (GUI) based operating system. Many implementations of such operating systems are well known and include the Apple Macintosh System 7 operating system, the MicroSoft MS-Windows 3.1, MS-Windows 95, MS-Windows NT, and the XWindows system, originally developed at MIT and used in many Unix based operating systems, including SunOS and Solaris.
The virtualization of the display in the form of a window permits some small conventional degree of flexibility in controlling where underlying data and programs are stored, whether an application program is locally or remotely executed and whether the display window or windows utilized by the particular application are locally or remotely displayed. Although these degrees of flexibility are conventionally available, collaborative use of an application program to interactively or simultaneously exchange and create information is not effectively supported. Conventional application programs remain by and large single user tools. As such, these applications co-exists in a networked environment constrained to sharing data through low level record and file locked access to shared data on network accessible storage devices.
Conventional collaborative application programs have been designed and implemented in an effort to support a greater degree of concurrent interactivity. Most conventional collaborative applications are highly proprietary in that the manner and nature of the permitted collaboration is strictly controlled by the particular application. Collaborative interaction is confined to the functions of that application. One manner by which such applications operate is through the establishment of a background server accessible by way of a network connection from each host that will participate in a collaborative session. On each participant host, a user executes an identical copy of the collaborative application. The application itself is responsible for initiating or joining a collaborative session by registering with the background server through a proprietary protocol, though typically overlaid on a conventional protocol such as TCP/IP. Thereafter, for the duration of the collaborative session, the application is responsible for duplicating all collaborative user input to the application and forwarding the copied input to the background server. In turn, the background server is responsible for re-distribution of all collaborative input from each participating host to all other participating hosts. Thus, each of the collaborative applications operate from the cumulative set of collaborative user input. Consequently, each application is expected to operate and present information in a synchronized manner.
Proprietary collaborative application programs, while generally functional for their intended purposes, are of limited collaborative value because the collaborative function supported is specifically limited to that of the particular application. Often, the particular requirements of a specific collaborative application program, in order to function as intended, may bar the use of other collaborative applications at the same time by the participating hosts. Furthermore, a high degree of administrative overhead, if not also computer processing overhead, is often required to support collaborative application programs. These costs are additive to the processing and administration requirements of the underlying operating system and networking support required by the application. Thus, collaborative applications have been effective most typically in situations where specialized use and particular functionality have been required.
An alternative to the use of proprietary collaborative application programs is a technology known as screen sharing. This technology provides for the information displayed on the display of a primary or host computer system to be projected across a network to another, or guest computer system. In general, screen sharing is implemented through establishment of a logical tap at the display device driver level of the host computer system. All display data is duplicated by way of this tap and passed through the network to the guest. On the guest system, the screen sharing application executes a logically inverse data tap to display the monitored screen data on the display of the guest.
Screen sharing therefore operates largely independent of the particular applications being executed on the host in addition to the screen sharing application. Screen sharing allows application independence to the point that collaborative sharing of well behaved though otherwise ordinary applications, including applications that otherwise could not be executed on a particular guest system, can be made subject to the collaboration.
Unfortunately, conventional screen sharing effectively precludes the private co-execution of other applications on both the host and all guest systems during the collaboration. All user input on both the host and guest systems is provided to the host executed applications. Thus, the entire function of the host and guest appears synchronized and limited to the collaboration. Consequently, screen sharing is predominately used to allow remote systems to monitor the display oriented aspects of the execution of applications on a single host system.
Another form of computer based collaboration is known as window sharing. In collaborative window sharing, the host system executes an otherwise conventional application within a window established and managed by a proprietary window sharing collaborative application. As with screen sharing, the principal operative feature of window sharing is a tapped duplication of the window display data for transfer to one or more guest systems participating in the window sharing collaboration. Each of these guests also executes the window sharing application, though configured to receive and display the tapped data in a similarly configured window on the guest system. Since a single application is being executed within the logical confines of the shared window, guest input data can also be tapped and provided to the local host at least in a two system collaboration session. If more than two systems are to participate share input data in a collaboration, a significantly more complex registration and input server system is generally required.
The window sharing technology is further constrained in general by the limitation that only a single application can be collaboratively shared within a single window. A collaboration session could be realized through a single window by execution of a succession of applications. To avoid the need to stop and restart applications, multiple windows may be supported by the window sharing application. As expected, the co-execution of applications in respective windows will contend with one another for system resources. However, the execution behavior of the shared applications may be unusual due to the potential of unexpected inputs. A first application may be executed on the host computer system and shared with one or more guests. If the user of that system changes the local input focus to a second window, corresponding to either a private, locally executed application or to another shared application window, the focus event will typically suspend execution of the first application until a focus event within the application's window returns execution focus to the first application. While suspended, the shared application will refuse all input except for a focus event, such as a mouse click within the shared window. Thus, all collaborative guests are suddenly and unexpectedly stopped in the midst of their collaboration.
A shared application focus event may also be generated on any of the guest systems. Consequently, a shared window may be suddenly and unexpectedly raised to active execution on the host by a guest focus event. That is, each time any collaborator at the host or any guest system introduces a focus event into a guest shared window, focus and execution will immediately switch to the shared application on the host and all guests. If multiple shared applications are being co-executed on the host, the contention for focus will be substantial. Thus, users at the host and guest executing one or more shared applications may be sharply limited if not barred as a practical matter from co-execution of other applications, shared or private. This characteristic of window sharing is, in general, poorly received by the users of such applications.
A combination window and screen sharing technology is also known. This technology provides for the sharing of the full screen on the host. The shared screen is, however, displayed in a window on a guest system. By sharing the full host screen, multiple host executed applications can be shared within a single collaboration session. Input events are mapped on the guest system to be window frame relative for events within the shared window. Consequently, a reasonably operative desk top is represented on the guest in the shared window.
However, the combined window and screen sharing technology inherits most if not all of the disadvantages of the individual screen sharing and window sharing technologies. On the host, no private applications can be executed since the entire screen is shared. While focus events from a guest outside of the guests' shared window will not be shared with the host, all host focus events will generate shared window focus events on a guest. Thus, any activity on the host or through the host from potentially other guests will raise the shared windows of all guests. The ability to execute private applications on the guest systems is therefore largely defeated.